Verification of hardware design for data transformation component

ABSTRACT

A hardware design for a main data transformation component is verified. The main data transformation component is representable as a hierarchical set of data transformation components which includes (i) a plurality of leaf data transformation components which do not have children, and (ii) one or more parent data transformation components which each comprise one or more child data transformation components. For each of the plurality of leaf data transformation components, it is verified that an instantiation of the hardware design for the leaf data transformation component generates an expected output transaction in response to each of a plurality of test input transactions. For each of the one or more parent data transformation components, it is formally verified, using a formal verification tool, that an instantiation of an abstracted hardware design for the parent data transformation component generates an expected output transaction in response to each of a plurality of test input transactions. The abstracted hardware design for the parent data transformation component represents each of the one or more child data transformation components of the parent data transformation component with a corresponding abstracted component that for a specific input transaction to the child data transformation component is configured to produce a specific output transaction with a causal deterministic relationship to the specific input transaction.

CROSS-REFERENCE TO RELATED APPLICATIONS AND CLAIM OF PRIORITY

This application is a continuation under 35 U.S.C. 120 of applicationSer. No. 17/065,678 filed Oct. 8, 2020, now U.S. Pat. No. 11,074,381,which claims foreign priority under 35 U.S.C. 119 from United KingdomApplication No. 1914552.3 filed Oct. 8, 2019.

BACKGROUND

Many electronic devices, such as systems-on-chips (SoCs), includehardware (e.g. an integrated circuit) that implements a datatransformation component. The term “data transformation” is used hereinto mean any operation or set of operations (e.g. mathematical operationssuch as, but not limited to, arithmetic operations including addition,subtraction, multiplication, division etc.) that can be performed on, orapplied to, a set of data to produce new data. Accordingly, a datatransformation component receives a set of one or more data inputs,performs a data transformation on the set of one or more data inputs,and outputs the result of the data transformation. When a datatransformation component generates a set of one or more outputs for aset of one or more inputs the component is said to execute a‘transaction’. Accordingly, a data transformation component is said toexecute the same transaction if it generates a set of one or moreoutputs for the same set of one or more inputs.

A data transformation component may be simple (e.g. it may calculate thesum of two numbers) or it may be complex (e.g. it may be a graphicsprocessing unit (GPU)). A data transformation component may implementthe data transformation via a single data transformation stage, or adata transformation component may implement the data transformation overa plurality of data transformation stages.

Generating hardware to implement a data transformation componenttypically includes developing a hardware design that describes thestructure and/or function of an integrated circuit that implements thedata transformation component; verifying or testing the hardware designto ensure that an integrated circuit manufactured according to thedesign will behave as expected; and once verified, manufacturing anintegrated circuit, at an integrated circuit manufacturing system, inaccordance with the hardware design.

In some cases, verifying the hardware design for a data transformationcomponent may comprise verifying that an instantiation of the hardwaredesign will generate the correct output, according to the datatransformation, for any set of inputs (i.e. for any input transaction).

A hardware design may be verified, for example, by formal verificationor simulation-based verification. Formal verification is a systematicprocess that uses a mathematical model of the hardware design andmathematical reasoning to verify the hardware design. In contrast,simulation-based verification is a process in which a hardware design istested by applying stimuli to an instantiation of the hardware designand monitoring the output of the instantiation of the hardware design inresponse to the stimuli.

In formal verification, the hardware design is transformed into amathematical model (e.g. a state-transition system, or a flow graph) tothereby provide an instantiation of the hardware design which can betested to verify the hardware design, and formal properties to beverified are expressed using mathematical logic using a precise syntaxor a language with a precise mathematical syntax and semantics.

Formal verification is performed using a formal verification tool (i.e.a software tool that is capable of performing formal verification of ahardware design). Formal verification tools include, but are not limitedto, formal property checkers such as OneSpin 360 DV™, Mentor GraphicsQuesta® Formal Verification, Synopsys® VC Formal, Cadence® Incisive®Enterprise Verifier, and JasperGold®; and formal equivalence checkers(which may also be referred to as formal model checkers) such asSynopsys® HECTOR, and other logical equivalence checkers (LECs) andsequential logical equivalence checkers (SLECs)).

Formal verification can improve controllability as compared tosimulation-based verification. Low controllability occurs when thenumber of simulation test signals or vectors required to thoroughlysimulate a hardware design becomes unmanageable. For example, a 32-bitcomparator requires 2⁶⁴ test vectors. This may take millions of years toverify exhaustively by simulation-based verification. By performingformal verification, the 32-bit comparator can be verified in less thana minute.

While formal verification can be an effective method for exhaustivelyverifying properties of a hardware design, this is only true if theproperties that are to be verified are presented in such a manner that aformal verification tool can solve the mathematical problem presentedthereby. Specifically, during formal verification of a hardware designthe hardware design is represented as a mathematical model, theproperties to be proved are also represented mathematically, andmathematical reasoning is used to determine if the properties are truefor the hardware design based on the mathematical model. In other words,in formal verification the verification is presented as a mathematicalproblem to be solved. Some mathematical problems will be solvable withina reasonable amount of time by a formal verification tool whereas otherswill not. When a formal verification tool is able to solve themathematical problem presented by the hardware design and the propertiesto be verified then the formal verification is said to converge. When,however, a formal verification tool is unable to solve the mathematicalproblem presented by the hardware design and the properties to beverified, then the formal verification does not converge, and no resultsare output, and the verification is inconclusive.

Many formal verification tools find it difficult to solve a mathematicalproblem presented by a hardware design and the properties to be verifiedthat involves calculating the result of a data transformation (e.g.arithmetic operation), particularly a mathematical problem that involvescalculating the result of a series or sequence of data transformations.

The embodiments described below are provided by way of example only andare not limiting of implementations which solve any or all of thedisadvantages of known methods and systems for verifying a hardwaredesign for a data transformation component.

SUMMARY

This summary is provided to introduce a selection of concepts that arefurther described below in the detailed description. This summary is notintended to identify key features or essential features of the claimedsubject matter, nor is it intended to be used to limit the scope of theclaimed subject matter.

Described herein are methods and systems for verifying a hardware designfor a main data transformation component. The main data transformationcomponent is representable as a hierarchical set of data transformationcomponents which includes (i) a plurality of leaf data transformationcomponents which do not have children, and (ii) one or more parent datatransformation components which each comprise one or more child datatransformation components. The method includes: (a) for each of theplurality of leaf data transformation components, verifying that aninstantiation of the hardware design for the leaf data transformationcomponent generates an expected output transaction in response to eachof a plurality of test input transactions; and (b) for each of the oneor more parent data transformation components, formally verifying, usinga formal verification tool, that an instantiation of an abstractedhardware design for the parent data transformation component generatesan expected output transaction in response to each of a plurality oftest input transactions. The abstracted hardware design for the parentdata transformation component represents each of the one or more childdata transformation components of the parent data transformationcomponent with a corresponding abstracted component that is configuredto for a specific input transaction to the child data transformationcomponent produce a specific output transaction with a causaldeterministic relationship to the specific input transaction. Duringformal verification the formal verification tool is configured to selectthe specific input transaction and the specific output transaction pairto be each possible valid input transaction and valid output transactionpair for the child data transformation component.

A first aspect provides a computer-implemented method of verifying ahardware design for a main data transformation component, the main datatransformation component being representable as a hierarchical set ofdata transformation components, the hierarchical set of datatransformation components comprising (i) a plurality of leaf datatransformation components which do not have children in the hierarchicalset of data transformation components, and (ii) one or more parent datatransformation components which each comprise one or more child datatransformation components in the hierarchical set of data transformationcomponents, wherein the hardware design for the main data transformationcomponent comprises a hardware design for each data transformationcomponent of the hierarchical set of data transformation components, themethod comprising at one or more processors: for each of the pluralityof leaf data transformation components, verifying that an instantiationof the hardware design for the leaf data transformation componentgenerates an expected output transaction in response to each of aplurality of test input transactions; and for each of the one or moreparent data transformation components, formally verifying, using aformal verification tool, that an instantiation of an abstractedhardware design for the parent data transformation component generatesan expected output transaction in response to each of a plurality oftest input transactions, wherein the abstracted hardware design for theparent data transformation component represents each of the one or morechild data transformation components of the parent data transformationcomponent with a corresponding abstracted component that is configuredto for a specific input transaction to the child data transformationcomponent produce a specific output transaction with a causaldeterministic relationship to the specific input transaction, whereinduring formal verification the formal verification tool is configured toselect the specific input transaction and the specific outputtransaction pair to be each possible valid input transaction and validoutput transaction pair for the child data transformation component.

The corresponding abstracted component for a child data transformationcomponent may be defined in a formal verification language by adefinition of a symbolic input transaction to the child datatransformation component which specifies the specific input transaction,a definition of a symbolic output transaction of the child datatransformation component which specifies the specific outputtransaction, and one or more constraints that establish a deterministiccausal relationship between the symbolic input transaction and thesymbolic output transaction.

The symbolic input transaction to the child data transformationcomponent may be a symbolic constant that represents the valid inputtransactions to the child data transformation component.

The symbolic output transaction to the child data transformationcomponent may be a symbolic constant that represents the valid outputtransactions for the child data transformation component.

The one or more constraints may be implemented by one or more formalassumption statements.

When a parent data transformation component comprises a plurality ofchild data transformation components the abstracted hardware design forthat parent data transformation component may comprise a description ofa relationship between the symbolic input and output transactions of theplurality of child data transformation components.

Each data transformation component of the hierarchical set of datatransformation components may be configured to receive one or more datainputs, perform a data transformation on the one or more data inputs,and output a result of the data transformation.

Verifying that an instantiation of the hardware design for a leaf datatransformation component generates an expected output transaction inresponse to an input transaction may comprise verifying that theinstantiation of the hardware design for the leaf data transformationcomponent generates an output transaction, with a deterministic causalrelationship to the input transaction, that is correct with respect to adata transformation to be performed by the leaf data transformationcomponent.

Verifying that an instantiation of the abstracted hardware design for aparent data transformation component generates an expected outputtransaction in response to an input transaction may comprise verifyingthat an instantiation of the abstracted hardware design for the parentdata transformation component generates an output transaction, with adeterministic causal relationship to the input transaction, that hasbeen generated by processing the input transaction through an expectedcombination of the one or more child data transformation components ofthat parent data transformation component.

The plurality of test input transactions for a leaf data transformationcomponent may comprise all valid input transactions to the leaf datatransformation component.

The plurality of test input transactions for a parent datatransformation component may comprise all valid input transactions tothe parent data transformation component.

Verifying that an instantiation of the hardware design for a leaf datatransformation component generates an expected output transaction inresponse to each of a plurality of test input transactions may compriseformally verifying, using a formal verification tool, that aninstantiation of the hardware design for the leaf data transformationcomponent generates an expected output transaction in response to eachof the plurality of test input transactions.

The method may further comprise outputting one or more control signalsindicating whether each of the verifications was successful.

The method may further comprise, in response to determining that atleast one of the verifications was not successful, determining whetherthe at least one of the verifications that was not successful wasinconclusive; and in response to determining that the at least one ofthe verifications that was not successful was inconclusive, representingthe main data transformation component using a different hierarchicalset of data transformation components, and repeating the verificationsfor at least a portion of the data transformation components of thedifferent hierarchical set of data transformation components.

The method may further comprise, in response to determining that theverification of the hardware design for a leaf data transformationcomponent was inconclusive, converting that leaf data transformationcomponent into a parent data transformation component that comprises aplurality of leaf data transformation components to form the differenthierarchical set of data transformation components, and verifying thehardware design for each of the plurality of child data transformationcomponents of that parent data transformation component and verifying anabstracted hardware design for that parent data transformationcomponent.

The method may further comprise, in response to determining that the atleast one verification that was not successful was not inconclusive,modifying the hardware design for the main data transformation componentto generate a modified hardware design for the main data transformationcomponent.

The method may further comprise, in response to determining that theverifications were successful, manufacturing, using an integratedcircuit manufacturing system, an integrated circuit embodying the maindata transformation component according to the hardware design.

When processed at an integrated circuit manufacturing system, thehardware design for the main data transformation component may configurethe integrated circuit manufacturing system to manufacture an integratedcircuit embodying the main data transformation component.

A second aspect provides a system for verifying a hardware design for amain data transformation component, the main data transformationcomponent being representable as a hierarchical set of datatransformation components, the hierarchical set of data transformationcomponents comprising (i) a plurality of leaf data transformationcomponents which do not have children in the hierarchical set of datatransformation components, and (ii) one or more parent datatransformation components which each comprise one or more child datatransformation components in the hierarchical set of data transformationcomponents, wherein the hardware design for the main data transformationcomponent comprises a hardware design for each data transformationcomponent of the hierarchical set of data transformation components, thesystem comprising: memory configured to store: the hardware design foreach of the plurality of leaf data transformation components; anabstracted hardware design for each of the one or more parent datatransformation components, wherein the abstracted hardware design for aparent data transformation component represents each of the one or morechild data transformation components of the parent data transformationcomponent with a corresponding abstracted component that is configuredto for a specific input transaction to the child data transformationcomponent produce a specific output transaction with a causaldeterministic relationship to the specific input transaction, whereinduring formal verification of the abstracted hardware design for a childdata transformation component a formal verification tool is configuredto select the specific input transaction and the specific outputtransaction pair to be each possible valid input transaction and validoutput transaction pair for the child data transformation component; andone or more verification tools comprising one or more formalverification tools; and one or more processors configured to: cause atleast one of the one or more verification tools to verify that aninstantiation of the hardware design for each of the plurality of leafdata transformation components produces an expected output transactionin response to each of a plurality of test input transactions; and causeat least one of the one or more formal verification tools to formallyverify that an instantiation of the abstracted hardware design for eachof the one or more parent data transformation components produces anexpected output transaction in response to each of a plurality of testinput transactions.

A hardware design for a data transformation component, when processed inan integrated circuit manufacturing system, configures the system tomanufacture an integrated circuit embodying the data transformationcomponent. There may be provided a non-transitory computer readablestorage medium having stored thereon a hardware design for a datatransformation component that, when processed in an integrated circuitmanufacturing system, causes the integrated circuit manufacturing systemto manufacture an integrated circuit embodying the data transformationcomponent.

There may be provided an integrated circuit manufacturing systemcomprising: a non-transitory computer readable storage medium havingstored thereon a hardware design for a data transformation component; alayout processing system configured to process the computer readabledescription so as to generate a circuit layout description of anintegrated circuit embodying the data transformation component; and anintegrated circuit generation system configured to manufacture anintegrated circuit embodying the data transformation component accordingto the circuit layout description.

There may be provided computer program code for performing a method asdescribed herein. There may be provided non-transitory computer readablestorage medium having stored thereon computer readable instructionsthat, when executed at a computer system, cause the computer system toperform the methods as described herein.

The above features may be combined as appropriate, as would be apparentto a skilled person, and may be combined with any of the aspects of theexamples described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples will now be described in detail with reference to theaccompanying drawings in which:

FIG. 1 is a flow diagram of an example method of verifying a hardwaredesign for a data transformation component;

FIG. 2 is a block diagram of an example main data transformationcomponent that is representable as a hierarchal set of datatransformation components;

FIG. 3 is a schematic diagram illustrating the verifications that areperformed in block 102 of the method of FIG. 1 for a hardware design forthe main data transformation component of FIG. 2 ;

FIG. 4 is a schematic diagram illustrating the verifications that areperformed in block 104 of the method of FIG. 1 for a hardware design forthe main data transformation component of FIG. 2 ;

FIG. 5 is a schematic diagram illustrating an example datatransformation component that is to be abstracted;

FIG. 6 is a block diagram of an example system for verifying a hardwaredesign for a data transformation component;

FIG. 7 is a block diagram of an example computing-based device;

FIG. 8 is a block diagram of an example computer system in which a datatransformation component described herein may be implemented; and

FIG. 9 is a block diagram of an example integrated circuit manufacturingsystem which may be used to generate an integrated circuit embodying adata transformation component described herein.

The accompanying drawings illustrate various examples. The skilledperson will appreciate that the illustrated element boundaries (e.g.,boxes, groups of boxes, or other shapes) in the drawings represent oneexample of the boundaries. It may be that in some examples, one elementmay be designed as multiple elements or that multiple elements may bedesigned as one element. Common reference numerals are used throughoutthe figures, where appropriate, to indicate similar features.

DETAILED DESCRIPTION

The following description is presented by way of example to enable aperson skilled in the art to make and use the invention. The presentinvention is not limited to the embodiments described herein and variousmodifications to the disclosed embodiments will be apparent to thoseskilled in the art. Embodiments are described by way of example only.

A “hardware design” is a description of the structure and/or function ofan integrated circuit which, when processed at an integrated circuitmanufacturing system, causes the integrated circuit manufacturing systemto generate an integrated circuit described by the hardware design. Forexample, as described in more detail below with respect to FIG. 9 , whena hardware design is processed at an integrated circuit manufacturingsystem the integrated circuit manufacturing system may generate theintegrated circuit by synthesizing the hardware design into silicon, or,by loading configuration data into a field-programmable gate array(FPGA).

A hardware design may be implemented in a high-level hardwaredescription language (HDL), such as, but not limited to, a registertransfer level (RTL) language. Examples of register transfer levellanguages include, but are not limited to, VHDL (VHSIC HardwareDescription Language) and Verilog®. It will be evident to a person ofskill in the art that other high-level hardware description languagesmay be used such as proprietary high-level hardware descriptionlanguages.

An “instantiation of a hardware design” is a representation of thehardware and/or functionality of the hardware defined by the hardwaredesign. An instantiation of a hardware design includes, but is notlimited to, an emulation model of the hardware design that mimics orreproduces the behaviour of the hardware defined by the hardware design,a synthesized version (e.g. netlist) of the hardware design, a hardwareimplementation (e.g. integrated circuit or a field-programmable gatearray (FPGA)) of the hardware design, and a mathematical model of thehardware design generated by a formal verification tool. Aninstantiation of the hardware design embodies the hardware design in aform which can be tested to verify the hardware design.

A hardware design for a data transformation component is thus adescription of the structure and/or function of an integrated circuit toimplement a data transformation component which, when processed at anintegrated circuit manufacturing system causes the integrated circuitmanufacturing system to generate an integrated circuit that embodies thedata transformation component. As described above, a data transformationcomponent is configured to receive one or more data inputs, perform adata transformation (e.g. perform one or more arithmetic operations) onthe one or more data inputs, and output the result of the datatransformation. Accordingly, a hardware design for a data transformationcomponent includes a description of the structure and/or function of thedata transformation performed on the one or more data inputs. Asdescribed above, a data transformation component may perform the datatransformation via one data transformation stage or via multiple datatransformation stages.

As described above, many formal verification tools have difficulty insolving mathematical problems defined by a hardware design andproperties to be verified that involve calculating the result of a datatransformation, and, particularly, calculating the result of a sequenceor set of data transformations. Accordingly, described herein arehierarchical methods and systems for verifying, via formal verification,a hardware design for a main data transformation component (which mayalternatively be referred to herein as the hardware design under test).Specifically, in the methods and systems described herein the main datatransformation component is described, or represented, as a hierarchicalset of data transformation components. The hierarchical set of datatransformation components comprises (i) a plurality of leaf datatransformation components; and (ii) one or more parent datatransformation components. A leaf data transformation component is adata transformation component that does not have any children in thehierarchy. In contrast, a parent data transformation component comprisesone or more child data transformation components. The child datatransformation component of a parent data transformation component maybe a leaf data transformation component or another parent datatransformation component. Accordingly, a parent data transformation canbe both a child data transformation component and a parent datatransformation component.

The data transformation components of the hierarchical set of datatransformation components can be grouped into a number of levels,wherein the level of a data transformation component is based on thenumber of ancestors the data transformation component has in thehierarchy. In some cases, the level of a data transformation componentmay be 1+the number of ancestors in the hierarchy. For example, a datatransformation at the root (i.e. top) of the hierarchy has no ancestorsand thus is a level 1 data transformation component. The children datatransformation components of the root data transformation component haveone ancestor (the root data transformation component) thus they arelevel 2 data transformation components. The children of a level 2 datatransformation component (i.e. the grandchildren of the root datatransformation component) have two ancestors—a level 2 datatransformation component and the root data transformation component,thus they are level 3 data transformation components. The closer a datatransformation component is to the root data transformation component,the higher the level of that data transformation component. Accordingly,the root data transformation component is at the highest level of thehierarchy, and a child data transformation component is always at alower level of the hierarchy than its parent data transformationcomponent. In general, different leaf data transformation components mayhave a different number of ancestors. Accordingly, the leaf datatransformation components may not all be at the same level within thehierarchy.

At least a portion of the hardware design for the main datatransformation component corresponds to each data transformationcomponent in the hierarchy. The portion of the hardware design thatrelates to, or describes, a data transformation component in thehierarchy may be referred to herein as the hardware design for that datatransformation component. In other words, the hardware design for themain data transformation component comprises a hardware design for eachdata transformation component in the hierarchy.

In some cases, as described in more detail below, the hierarchical setof data transformation components that are used to represent the maindata transformation component may vary during the verification. Forexample, if the verification(s) performed using a first hierarchical setof data transformation components do not converge or are inconclusive,the main data transformation component may be represented by a second,different, hierarchical set of data transformation components and theverification(s) may then be performed for at least a portion of the datatransformation components in the second hierarchical set of datatransformation components.

The hardware design for the main data transformation component isverified by verifying the hardware designs for each data transformationcomponent in the hierarchy separately. This allows the mathematicalproblem of verifying the hardware design to be divided into manageablepieces. However, the data transformation components at higher levels inthe hierarchy get more and more complicated as they encompass more andmore lower level data transformation components. Accordingly, tosimplify the verification of the hardware design for a parent datatransformation component, the description of each child datatransformation component in that hardware design is replaced with adescription of an abstracted component (e.g. a formal description of theabstracted component written in a formal verification language) togenerate an abstracted hardware design for the parent datatransformation component. The description of the child datatransformation component can be abstracted because the child datatransformation component itself will be verified.

For example, when verifying the hardware design for the parent datatransformation of a leaf data transformation component, the descriptionof the leaf data transformation component can be replaced with adescription (e.g. a formal description) of a corresponding abstractedcomponent in the hardware design for the parent data transformationcomponent. In the examples described herein the abstracted component isconfigured to, for a specific input transaction to the datatransformation component that it replaces, generate a specific outputtransaction at the appropriate time according to the specification forthe data transformation component, wherein the specific inputtransaction and the specific output transaction are dynamically selectedby a formal verification tool from a set of possible input transactionsand a set of possible output transactions respectively. During formalverification the formal verification tool is configured to select thespecific input transaction and the specific output transaction pair tobe each possible input transaction and output transaction pair. In thisway the complex data transformation logic that formal verification toolsfind difficult to deal with is removed from the hardware designs of allbut the leaf data transformation components.

Although the example verification methods and systems described beloware described for use in verifying a hardware design for a datatransformation component, the methods and systems described herein maybe used to verify the hardware design for any component that can berepresented as, or described by, a hierarchical set of components. It isnoted that the described methods and systems have proven particularlyuseful in verifying complex components, such as GPUs.

Reference is now made to FIG. 1 which illustrates an examplehierarchical method 100 for verifying a hardware design for a main datatransformation component. The method 100 may be implemented by acomputing-based device such as, but not limited to, the computing-baseddevice 700 described below with respect to FIG. 7 . For example, theremay be a computer readable storage medium having stored thereon computerreadable instructions that, when executed at a computing-based device,cause the computing-based device to perform the method 100 of FIG. 1 .

In the examples described herein the main data transformation componentcan be represented by, or described as, a hierarchical set of datatransformation components. The hierarchical set of data transformationcomponents comprises a plurality of levels of data transformationcomponents. The plurality of levels of data transformation componentscomprises a plurality of leaf data transformation components, and one ormore parent data transformation components. Each parent datatransformation component comprises at least one data transformationcomponent of the next lower level (which may be referred to herein asthe child data transformation component of that parent datatransformation component). The hierarch (i.e. root) component of thehierarchy (i.e. the component at the highest level of the hierarchy) isthe main data transformation component itself.

At least a portion of the hardware design for the main datatransformation component corresponds to each data transformationcomponent in the hierarchy. The portion of the hardware design for themain data transformation component that relates to, or describes, a datatransformation component in the hierarchy may be referred to herein asthe hardware design for that data transformation component. In somecases, the hardware design for the main data transformation componentmay be implemented in a hierarchical manner such that the portions ofthe hardware design pertaining to each data transformation component inthe hierarchy are easily discernible. In other cases, the method 100 mayfurther comprise describing, or representing, the main datatransformation component as a hierarchical set of data transformationcomponents and identifying the portion of the hardware design for themain data transformation component that relates to each datatransformation component in the hierarchy.

FIG. 2 shows an example data transformation component 200 which isrepresented by a hierarchical set of data transformation components 202,204, 206, 208, 210, 212, 214. Each data transformation componentreceives a set of one or more inputs (i.e. an input transaction),performs a data transformation on the set of one or more inputs, andoutputs the result(s) of the data transformation (i.e. an outputtransaction). For example, one data transformation component (e.g. 208)may add two input values, whereas another data transformation component(e.g. 210) may calculate the square root of an input value. AlthoughFIG. 2 shows only the data transformation components of the main datatransformation component 200 it will be evident to a person of skill inthe art that the main data transformation component 200 may compriseother components, such as, but not limited to, control logic andregisters.

In the example of FIG. 2 the hierarchical set of data transformationcomponents comprises three levels of data transformation componentsnumbered 1 to 3 wherein level 1 is the highest level. There is a singledata transformation component 202 at the top level (level 1) whichrepresents the main data transformation component. The level 1 datatransformation component 202 comprises two level 2 data transformationcomponents 204, 206. Each level 2 data transformation component 204 and206 comprises two level 3 data transformation components. Specifically,the first level 2 data transformation component 204 comprises the firstand second level 3 data transformation components 208 and 210, and thesecond level 2 data transformation component 206 comprises the third andfourth level 3 data transformation components 212 and 214.

The lower level data transformation components that form part of ahigher level data transformation component may be referred to as thesubordinate data transformation components, or the child datatransformation components, of that higher level component. For example,the first and second level 3 components 208 and 210 are subordinates orchildren of the first level 2 data transformation component 204.Similarly, the higher level data transformation component whichincorporates a lower level data transformation component is referred toas the superior or parent of that lower level data transformationcomponent. For example, the first level 2 data transformation component204 is a superior, or a parent, of the first and second level 3 datatransformation components 208 and 210.

The data transformation components that do not comprise another datatransformation component (i.e. do not have any children) are referred toas leaf data transformation components. For example, the level 3 datatransformation components 208, 210, 212 and 214 do not comprise anyother data transformation components and thus are leaf datatransformation components. Although all of the leaf data transformationcomponents are shown in FIG. 2 as being at the same level, in otherexamples, the leaf data transformation components may be at differentlevels of the hierarchy.

In the methods described herein the hardware design for each datatransformation component in the hierarchy is verified separately and theverification of a parent data transformation component is simplified byreplacing the description of any child data transformation component inthe hardware design for the parent data transformation component with adescription of an abstracted component. Specifically, as described inmore detail below, in some cases the logic that implements or performsthe data transformation of that child data transformation component isreplaced with logic that for a specific input transaction produces aspecific output transaction at the correct time (according to thespecification for that data transformation component), wherein thespecific input transaction and the specific output transaction aredynamically selected by a formal verification tool from a set ofpossible input transactions and a set of possible output transactionsrespectively. The set of possible input transactions from which thespecific input transaction is selected may be all valid inputtransactions. The set of possible output transactions from which thespecific output transaction is selected may be all valid outputtransactions. During formal verification, the formal verification toolis configured to select the specific input and output transaction pairto be each possible input and output transaction pair. This allows thespecifics of the data transformation(s) to be removed from the hardwaredesigns of all but the leaf data transformation components, yet theinteractions between the components to be verified.

The method 100 begins at block 102, where the hardware design for eachleaf data transformation component is verified to ensure that aninstantiation of the hardware design for the leaf data transformationcomponent will work as expected. For example, for the example main datatransformation component 200 of FIG. 2 the hardware design for eachlevel 3 data transformation component 208, 210, 212, 214 is verified asshown in FIG. 3 . Verifying that a hardware design for a leaf datatransformation component will work as expected may comprise formallyverifying that an instantiation of the hardware design for the leaf datatransformation component generates an expected output transaction inresponse to each of a plurality of input transactions. The plurality ofinput transactions may comprise all valid input transactions for theleaf data transformation component.

In some cases, formally verifying that an instantiation of the hardwaredesign for a leaf data transformation component will work as expectedmay comprise formally verifying that an instantiation of the hardwaredesign always produces the ‘correct’ output, with respect to the datatransformation that the leaf data transformation component is configuredto perform, in response to each valid input transaction. In these cases,the expected output transaction for an input transaction is the‘correct’ or expected result of the data transformation for the inputtransaction. For example, if a leaf data transformation component isdesigned to calculate the sum of two inputs a and b then the expectedoutput for any input transaction may be the sum of the two inputs (i.e.a+b).

In other cases, formally verifying that an instantiation of the hardwaredesign for a leaf data transformation component will work as expectedmay comprise formally verifying that an instantiation of the hardwaredesign is consistent (i.e. that it will always produce the same outputtransaction in response to the same input transaction regardless of whenthe input transaction is processed by the instantiation of the hardwaredesign for the leaf data transformation component). For example, if aleaf data transformation component is designed to calculate the sum oftwo inputs a and b then the leaf data transformation component mayreceive a particular a and b pair (e.g. a=5 and b=6) as inputs at cycle0 and it may receive the same a and b pair (e.g. a=5 and b=6) again incycle 10. The leaf data transformation component is ‘consistent’ if itproduces the same output in response to each matching a and b pair (e.g.each a=5 and b=6). Accordingly, in these cases the expected outputtransaction is the same output transaction that the instantiationproduced the first time it processed that input transaction, notnecessarily the ‘correct’ output transaction with respect to the datatransformation component that the leaf data transformation component isconfigured/designed to perform.

Regardless of whether it is verified that the output is ‘correct’ or theoutput is ‘consistent’; to verify that the output transaction producedin response to an input transaction is the expected output transaction,the verifier has to know when the output transaction corresponding to aparticular input transaction is to be output. This is based on thespecification for the leaf data transformation component. Accordingly,verifying that an expected output transaction is generated in responseto an input transaction also verifies that the output transaction isproduced or output at the correct time(s) (e.g. the output transactionmay comprise outputs that are produced over a plurality of cycles). Inother words, verifying that an instantiation of hardware designgenerated an expected output transaction in response to an inputtransaction also verifies that the output transaction has the expectedcausal relationship to the input transaction. As described in moredetail below, this means that when verifying the parent datatransformation component of a leaf data transformation component it canbe assumed that the leaf data transformation component will, for any ofthe verified input transactions, generate an output transaction with theexpected causal relationship to the input transaction.

Formally verifying that an instantiation of the hardware design for aleaf data transformation component generates an expected outputtransaction in response to each of a plurality of input transactions maycomprise generating a test bench in a formal verification language, suchas, but not limited to SVA, comprising one or more assertions to beverified and optionally one or more constraints (e.g. assumptions)and/or modelling logic; linking the test bench to the hardware designfor the leaf data transformation component; and formally verifying,using a formal verification tool, that the one or more assertions aretrue (or hold) for the hardware design for the leaf data transformationcomponent, and outputting one or more signals indicating whether the oneor more assertions were successfully verified.

An assertion is a statement that a particular property is expected tohold for a hardware design (i.e. is always true). An assertion of theform “assert property [evaluable expression]” is said to “assert” theproperty specified by the “evaluable expression”. If an assertedproperty (e.g. the evaluable expression) is evaluated to be false forthe hardware design for any valid input the hardware design is notbehaving as expected and there is an error. For example, in the exampleassertion “assert property a=b”; if a is not equal to b at any pointthen the hardware design is not behaving as expected and there is anerror.

Assertions are used to capture required temporal and combinationalbehaviour of the hardware design in a formal and unambiguous way. Thehardware design can then be verified to determine that it conforms tothe requirement as captured by the assertion(s). Since assertionscapture the hardware design behaviour on a cycle-by-cycle basis they canbe used to verify intermediate behaviours.

Assertions are typically expressed in an assertion language. Anassertion language, which may also be referred to as a property languageor a formal verification language, captures the hardware designbehaviour spread across multiple hardware design cycles (e.g. clockcycles) in a concise, unambiguous manner. While traditional hardwaredescription languages (HDL), such as an RTL language, have the abilityto capture individual cycle behaviour, they are too detailed to describeproperties at a higher level. In particular, assertion languages providemeans to express temporal relationships and complex hardware designbehaviours in a concise manner. Assertion languages include, but are notlimited to, System Verilog Assertions (SVA), Property SpecificationLanguage (PSL), Incisive Assertion Library (IAL), Synopsys OVA (OpenVeraAssertions), Symbolic Trajectory Evaluation (STE), SystemC Verification(SCV), 0-In, Specman, and OpenVera Library (OVL).

The hierarchy of data transformation components may be designed orconfigured such that the leaf data transformation components arerelatively simple data transformation components and/or performrelatively simple data transformations. Example methods of verifying thecorrectness or consistency of a data transformation component using oneor more assertions are described in the Applicant's co-pending UK PatentApplication Nos. 1805722.4, 1805723.2, 1818105.7 and 1818108.1, whichare herein incorporated by reference in their entirety.

The test bench (including the one or more assertions) may be linked tothe hardware design for the leaf data transformation component byincorporating the test bench into the hardware design for the leaf datatransformation component or binding the test bench to the hardwaredesign for the leaf data transformation component. Specifically, thetest bench may be bound to the relevant signals of the hardware designfor the leaf data transformation component to determine when theinstantiation has received one of the relevant input transactions, andto determine whether the output transaction is as expected.

Once the test bench has been linked to the hardware design for the leafdata transformation component, the hardware design for the leaf datatransformation component, the test bench, and the bindings are loadedinto a formal verification tool and the formal verification tool isconfigured to verify that the one or more assertions are true for thehardware design for the leaf data transformation component.

An assertion is verified by searching the entire reachable state spaceof the instantiation of the hardware design (e.g. state-transitionsystem, or flow graph) without explicitly traversing all the states. Thesearch is done by, for example, encoding the states using efficientBoolean encodings using Binary decision diagrams (BDDS), or usingadvanced SAT (satisfiability-based bounded model checking) basedtechniques. In some cases, tools can be used to implement techniques,such as, but not limited to, abstraction, symmetry, symbolic indexing,and invariants to improve performance and achieve scalability. Sinceformal verification of a property algorithmically and exhaustivelyexplores all valid input values over time, verifying a property in thismanner allows a property to be exhaustively proved or disproved for allvalid states.

Once the leaf data transformation components have been verified themethod 100 proceeds to block 104.

At block 104, the hardware design for each parent data transformationcomponent is verified. Verifying each parent data transformationcomponent may comprise (i) replacing, in the hardware design for theparent data transformation component, the description of each child datatransformation component thereof with a description of a correspondingabstracted component, to generate an abstracted hardware design for theparent data transformation component; and (ii) formally verifying thatan instantiation of the abstracted hardware design for the parent datatransformation component generates an expected output transaction inresponse to each of a plurality of test input transactions. In somecases, the plurality of test input transactions may be the set of allvalid input transactions to the parent data transformation component.

As described above, the expected output in the verifications performedin block 102 is the expected or correct result of the datatransformation performed by the leaf data transformation component (ifverifying correctness); or is the same output generated the first timethat input transaction was processed by the instantiation of the datatransformation component (if verifying consistency). However, in block104 the logic performing the data transformation(s) has been removed inthe abstracted hardware designs so the expected output in theverifications performed in block 104 is an output that has beengenerated by processing the input transaction by an expected set ofchild data transformation components thereof. Accordingly, in block 104it is verified that for each of the plurality of input transactions thatan instantiation of the abstracted hardware design produces an output atthe correct, or expected time, and that the output has been generated byprocessing the input transaction at the expected set of child datatransformation components. For example, if the parent datatransformation component comprises a first child data transformationcomponent that is configured to calculate the sum c of two inputs a andb, and a second child data transformation component that is configuredto calculate the product of d of c and 4 then in block 104 it may beverified that for any input pair a and b the output d, appears at thecorrect or expected time, and that d was generated by processing a and bat the first child data transformation component and then at the secondchild data transformation component.

For example, for the example main data transformation component 200 ofFIG. 2 there are three parent data transformation components—the twolevel 2 data transformation components 204, 206 and the one level 1 datatransformation component 202. Therefore executing block 104 for the maindata transformation component 200 of FIG. 2 comprises verifying thehardware design for each level 2 data transformation component 204, 206and verifying the hardware design for the level 1 data transformationcomponent 202.

This comprises generating an abstracted hardware design for each level 2data transformation component 204, 206 in which the description of eachlevel 3 data transformation component therein is replaced with adescription of a corresponding abstracted component. For example, asshown in FIG. 4 , an abstracted hardware design 404 for the first level2 data transformation component 204 of FIG. 2 may be generated byreplacing the description of the first level 3 data transformationcomponent 208 in the hardware design with a description of acorresponding abstracted component 408, and replacing the description ofthe second level 3 data transformation component 210 in the hardwaredesign with a description of a corresponding abstracted component 410.Similarly, an abstracted hardware design 406 for the second level 2 datatransformation component 206 may be generated by replacing thedescription of the third level 3 data transformation component 212 inthe hardware design with a description of a corresponding abstractedcomponent 412, and replacing the description of the fourth level 3 datatransformation component 214 with a description of a correspondingabstracted component 414.

It is then formally verified that (a) an instantiation of the abstractedhardware design for the first level 2 component 404 generates anexpected output transaction in response to each of a plurality of inputtransactions; and (b) an instantiation of the abstracted hardware designfor the second level 2 component 406 generates an expected outputtransaction in response to each of a plurality of input transactions.

Then an abstracted hardware design for the level 1 data transformationcomponent 202 is generated in which each level 2 data transformationcomponent therein is replaced with a description of an abstractedcomponent. For example, as shown in FIG. 4 an abstracted hardware design402 for the level 1 component 202 of FIG. 2 may be generated byreplacing the description of the first level 2 component 204 in thehardware design with a description of a corresponding abstractedcomponent 416, and replacing the description of the second level 2component 206 in the hardware design with a description of acorresponding abstracted component 418.

It is then formally verified that an instantiation of the abstractedhardware design for the level 1 data transformation component 402generates an expected output transaction in response to each of aplurality of input transactions.

In the examples described herein, the abstracted component that replacesa child data transformation component is configured to, for a specificinput transaction for the child data transformation component, produce aspecific output transaction with a deterministic causal relationshipthereto (e.g. at the correct time) according to the specification forthat child data transformation component, wherein the specific inputtransaction and the specific output transaction are dynamically selectedby a formal verification tool from a plurality of possible inputtransactions and a plurality of possible output transactionsrespectively. During formal verification, the formal verification toolis configured to select the specific input and output transaction pairto be each possible input and output transaction pair. In some cases,the plurality of possible input transaction may be all valid inputtransactions for the child data transformation component. In some cases,the plurality of possible output transactions may be all valid outputtransactions for the child data transformation component. It is notedthat the specific output transaction does not have to be the correctoutput transaction for the specific input transaction. For example, ifthe data transformation component is configured to calculate the squareroot of an input, then if the specific input transaction is 25 thespecific output transaction does not have to be 5, it can be any validoutput value.

A child data transformation component can be abstracted in this mannerbecause it has been verified in block 102 or block 104 that aninstantiation of the hardware design of the child data transformationcomponent will work as expected. In general, a property of a child datatransformation component that has been proven (or will be proven) to betrue can be assumed to be true in verifications of the parent datatransformation components of that child data transformation component.As is known to those of skill in the art, the specification for acomponent defines the requirements or properties of that component. Howthe requirements or properties set out in the specification areimplemented in the component is up to the architect, engineer orhardware designer who designs the component.

An ‘input transaction’ for a component is the set of one or more inputsthat are taken into account in generating the output for the component.In other words, an ‘input transaction’ for a component comprises the setof one or more inputs which influence the output of the component.Examples of other inputs that may not influence the output of thecomponent include, but are not limited to, control signals. The inputsforming an input transaction may be received by the component in thesame cycle or received by the component over several cycles. Forexample, a first input of an input transaction may be received in onecycle and a second input of the input transaction may be received in thenext cycle. FIG. 5 illustrates an example data transformation component500 which receives two inputs a and b, performs a data transformation ron a and b to produce c and d, and outputs c and d three cycles after aand b are received. An input transaction for the example component 500of FIG. 5 may comprise an a and b pair received in the same cycle.

Similarly an ‘output transaction’ for a component is the set of one ormore outputs that are generated in response to an input transaction. Theoutputs forming an output transaction may be output by the component inthe same cycle or different cycles. For example, a first output of anoutput transaction may be output in one cycle and a second output of anoutput transaction may be output in the next cycle. For example, anoutput transaction for the example component 500 of FIG. 5 may be a cand d pair. The specific manner in which the output transaction iscalculated from the input transaction is not specified in the abstractedcomponent.

Since a data transformation component generates output data that is atransformed version of the corresponding input data, the output datacorresponding to particular input data may be different than the inputdata. Accordingly, the abstracted component typically has a mechanism torelate input transactions to their corresponding output transaction. Forexample, the abstracted component may implement a sideband ID that isattached to the input data. The sideband ID may then be output alongwith the corresponding output data to relate input data and output data.In other cases, the abstracted component may be configured to relateinput data to its corresponding output data via a first-in-first-outmechanism. For example, an abstracted component may be configured tokeep track of the number of inputs and the number of outputs and relateinputs to outputs based on the counter. It will be evident to a personof skill in the art that these are examples only, and that theabstracted components may implement other suitable mechanisms forrelating inputs to outputs.

Replacing the example data transformation component 500 of FIG. 5 withan abstracted component that is configured to, for a specific inputtransaction, produce a specific output transaction with a deterministicrelationship thereto (e.g. at the correct time) wherein the particularinput transaction is dynamically selected from a set of possible inputtransactions and the particular output transaction is dynamicallyselected from a set of possible output transactions, may comprisereplacing this component with a component that is configured to, when itreceives a particular set of a and b (i.e. particular inputtransaction), output a particular set of c and d (i.e. particular outputtransaction) three cycles after a and b are received, wherein theparticular set of a and b is selectable from all possible combinationsof a and b and the particular set of c and d is selectable from allpossible combinations of c and d.

In some cases, the description of a child data transformation componentin a hardware design for a parent data transformation component may bereplaced with a description of an abstracted component that isconfigured to, for a specific input transaction, produce a specificoutput transaction at the correct time wherein the specific input andoutput transactions are dynamically selected from a set of possibleinput transactions and a set of possible output transactionsrespectively, by replacing the description of the child datatransformation component in the hardware design for the parent datatransformation component with: (a) a formal definition of a symbolicinput transaction for the child data transformation component; (b) aformal definition of a symbolic output transaction for the child datatransformation component; and (c) one or more formal constraints thatlink the symbolic input transaction to the symbolic output transactionin a deterministic manner so that the symbolic output transaction isproduced (i.e. output) at the correct time. In other words, the one ormore formal constraints create a deterministic causal relationshipbetween the symbolic input transaction and the symbolic outputtransaction. The replacement of the description of a data transformationcomponent with a symbolic input transaction, a symbolic outputtransaction and a set of one or more constraints defining thedeterministic causal relationship between the symbolic input transactionand the symbolic output transaction is referred to herein as replacingthe data transformation component with a deterministic input/outputpair.

The symbolic input transaction is a symbolic constant that is used torepresent a set of possible input transactions. As is known to those ofskill in the art of formal verification, a symbolic constant is aspecific formal verification construct that is associated with aplurality of possible values (or a plurality of sets of values). Duringformal verification of a property of a hardware design comprising asymbolic constant, the symbolic constant has a constant value or set ofvalues, but the formal verification tool verifies the property is truefor each possible value or each possible set of values for the symbolicconstant. Specifically, during a particular proof the value(s) for thesymbolic input transaction are constant but all possible values for thesymbolic input transaction are explored.

For example, if an example data transformation component receives inputsa and b wherein a can be between 0 and 5 and b can be between 1 and 20then a symbolic input transaction for this data transformation componentmay be defined as a combination of a and b wherein a can be between 0and 5 and b can be between 1 and 20. During formal verification theformal verification tool explores all possible symbolic inputtransactions (e.g. it explores a symbolic input transaction of a=1 andb=15 and a symbolic input transaction of a=2 and b=10 etc.). As aresult, a symbolic constant provides a very efficient means to verify aplurality of values or sets of values. A symbolic constant mayalternatively be referred to as a symbolic variable or a pseudoconstant. In some cases, the symbolic input transaction may be used torepresent all valid input transactions to the child data transformationcomponent. What constitutes a valid input transaction will depend on thechild data transformation component that is being replaced and thespecification thereof.

The following is example SVA code that defines a symbolic inputtransaction for an example data transformation component that receivesan input x that can be any 32 bit binary number, performs a datatransformation on x to produce y which can be any 64 bit binary number,and then outputs y three cycles after x is received.

logic [31:0] symbolic_input_value; assume($stable(symbolic_input_value));

As is known to those of skill in the art, the first line of the aboveSVA code defines a local 32 bit signal symbolic_input_value that isinitialised to a value between 0 and 2³²−1 during a proof. The secondline of the above SVA code is an assumption statement (i.e. constraint)that forces the value of symbolic_input_value to be constant throughouta proof.

The symbolic output transaction, like the symbolic input transaction, isa symbolic constant. However, instead of representing a set of inputtransactions, the symbolic output transaction is used to represent a setof output transactions. For example, if an output transaction is definedby outputs c and d where c can be between 10 and 20 and d can be between1 and 20 then a symbolic input transaction may be defined as acombination of c and d wherein c can be any number between 10 and 20 andd can be any number between 1 and 20. In some cases, the set of outputtransactions that are represented by the symbolic output transaction maybe all valid output transactions for the child data transformationcomponent.

The following is example SVA code that defines a symbolic outputtransaction for an example data transformation component that receivesan input x that can be any 32 bit binary number, performs a datatransformation on x to produce y which can be any 64 bit binary number,and then outputs y three cycles after x is received.

logic [63:0] symbolic_output_value; assume($stable(symbolic_output_value));

As is known to those of skill in the art, the first line of the aboveSVA code defines a local 64-bit signal symbolic_output_value that isinitialised to a value between 0 and 2⁶⁴−1 when a thread of the code isinitialised. The second line of the above SVA code is an assumptionstatement (i.e. constraint) that forces the value ofsymbolic_output_value to be constant throughout a proof.

The one or more formal constraints link the symbolic input transactionto the symbolic output transaction in a deterministic manner so that thesymbolic output transaction for a particular symbolic input transactionis produced at the correct time. The constraints may be implemented viaone or more formal assumption statements. As is known to those of skillin the art of formal verification, an assumption statement in, orrelated, to a component imposes a constraint on the operation of thatcomponent. An example assumption statement to link the symbolic inputtransaction to the symbolic output transaction for the example datatransformation component 500 of FIG. 5 may state that if the inputtransaction is the symbolic input transaction (a specific a and bcombination) then the symbolic output transaction (a specific c and d)is output three cycles after the symbolic input transaction is received.

The following is example SVA code for a formal constraint (e.g.assumption statement) that links the symbolic input transaction to thesymbolic output transaction for an example data transformation componentthat receives an input x that can be any 32 bit binary number, performsa data transformation on x to produce y which can be any 64 bit binarynumber, and then outputs y three cycles after x is received. In thisexample input_x is the input x to the data transformation component,symbolic_input_value is the symbolic input transaction/value, output_yis the output y of the data transformation component, andsymbolic_output_value is the symbolic output transaction/value.

assume (input_x == symbolic_input_value) | -> ##3 (output_y ==symbolic_output_value)

As is known to those of skill in the art, the above assumption statesthat if the input (input_x) is the symbolic input transaction(symbolic_input_value) then three cycles later (##3) the output(output_y) is the symbolic output transaction (symbolic_output_value).This will cause the symbolic output transaction (which will be aparticular value between 0 and 2⁶⁴−1) to be output three cycles afterthe symbolic input transaction (which will be a particular value between0 and 2³²−1) is received. During formal verification of a property ofhardware design comprising the above code, the formal verification toolverifies the property to be true when the symbolic input transaction(symbolic_input_value) and the symbolic output transaction(symbolic_output_value) pair are each possible input-output pair.

One of the advantages of abstracting data transformation components witha corresponding deterministic input/output pair is that this abstractiontechnique can be used for any data transformation component regardlessof the complexity of the data transformation (e.g. arithmeticoperation(s)) performed by the data transformation component.Specifically, the deterministic input/output pair abstraction method canbe used for any data transformation component so long as the inputs thatinfluence the output of that data transformation (i.e. the inputsdefining an input transaction) are known.

In some cases, where a parent data transformation component comprises aplurality of child data transformation components, the abstractedhardware design for the parent data transformation component may also bemodified/configured so as to link the deterministic input/output pairsof the child data transformation components so as to be able to verifythat an input is processed by the desired combination of child datatransformation components. For example, where a parent datatransformation component comprises a first child data transformationcomponent A that receives input x, performs a data transformation on xto produce an output y; and a second child data transformation componentB that receives input y, performs a data transformation on y to producean output z, the symbolic output transaction of the first child datatransformation component may be linked or matched to the symbolic inputtransaction of the second child data transformation component B. Thisallows it to be verified that the output of the parent datatransformation component is A(B(x)) without specifying what specificdata transformations are performed by A and B. An example of how thesymbolic inputs and outputs of the child data transformation componentsmay be linked is described below.

Once the abstracted hardware design for a parent data transformationcomponent has been generated, it is formally verified that aninstantiation of the abstracted hardware design will produce an expectedoutput transaction in response to each of a plurality of inputtransactions. In some cases, the input transactions comprise all validinput transactions into the parent data transformation component. Asdescribed above, as the logic that performs the data transformation(e.g. arithmetic calculation) is removed from the abstracted hardwaredesign, this verification does not verify that the instantiation of theabstracted hardware design transforms the data correctly, only that foreach of the plurality of input transactions the corresponding outputtransaction occurs at the correct time and that the input transaction isprocessed by, or passes through, the correct child data transformationcomponents in the correct order.

Formally verifying that an instantiation of the abstracted hardwaredesign for a parent data transformation component will produce anexpected output transaction in response to each of a plurality of testinput transactions may comprise generating a test bench in a formalverification language, such as, but not limited to SVA, that defines oneor more assertions to be verified (and optionally one or moreassumptions/constraints and/or modelling logic); linking the test benchto the abstracted hardware design for the parent data transformationcomponent; and formally verifying, using a formal verification tool,that the one or more assertions are true (or hold) for the abstractedhardware design for the parent data transformation component, andoutputting one or more signals indicating whether the one or moreassertions were successfully verified.

The following is example SVA code for abstracting the child datatransformation components of a parent data transformation component thatcomprises a first child data transformation component C1 that receivesinputs a and b, performs a data transformation on a and b to produce cand which is output three cycles after a and b are received; and asecond child data transformation component C2 that receives input c,performs a data transformation on c to produce d which is output onecycle after c is received; and example SVA code for an assertion toverify the operation of the abstracted hardware design for the parentdata transformation component.

In this example c1_a_in is the first input a to the first child datatransformation component C1; c1_b_in is the second input b to the firstchild data transformation component C1; c1_c_out is the output c of thefirst data transformation component; c2_c_in is the input c to thesecond child data transformation component C2; c2_d_out is the output dof the second data transformation component C2; top_in_a is the firstinput a to the parent data transformation component; top_in_b is thesecond input b to the parent data transformation component; top_out_d isthe output d of the parent data transformation component; watched_a isthe symbolic input a, watched_b is the symbolic input b (togetherwatched_a and watched_b define the symbolic input transaction);watched_c is the symbolic output/input c; and watched_d is the symbolicoutput d.

//Abstracted component for first child data transformation componentassume property ( (c1_a_in == watched_a) && (c1_b_in == watched_b) ) |-> ##3 (c1_c_out == watched_c) ; //Abstract component for second childdata transformation component assume property (c2_c_in == watched_c) |-> ##1 (c2_d_out == watched_d); //Assertion to verify parent datatransformation component assert property ( (top_in_a == watched_a) &&(top_in_b == watched_b) ) | -> ##4 (top_out_d == watched_d)

A person of skill in the art would understand that the first line ofcode (starting with “assume property ((c1 . . . ”) sets out a constraintthat when the input to the first child data transformation component C1is the symbolic input transaction (i.e. when input a is the symbolic a(c1_a_in==watched_a) and input b is the symbolic b (c1_b_in==watched_b))then the symbolic output transaction will be output(c1_c_out==watched_c) three cycles (##3) after the symbolic inputtransaction is received.

A person of skill in the art would understand that the second line ofcode (starting with “assume property ((c2 . . . ”) sets out a constraintthat when the input to the second child data transformation component C2is the symbolic input transaction (i.e. when input c is the symbolic c(c2_c_in==watched_c)) then the symbolic output will be output(c2_d_out==watched_d) one cycle (##1) after the symbolic inputtransaction is received. It can be seen that the symbolic input to C2 isset to the symbolic output of the first child data transformationcomponent C1 so as to link the two child data transformation components.

A person of skill in the art would understand that the third line ofcode (starting with “assert property . . . ”) is an assertion thatstates when the input to the parent data transformation component is thesymbolic input transaction to the first child data transformationcomponent (top_in_a==watched_a) && (top_in_b==watched_b)) then theoutput of the parent data transformation is the symbolic outputtransaction of the second child data transformation component(top_out_d==watched_d). Verifying this assertion, using a formalverification tool, for each valid input to the parent datatransformation component, verifies that each valid input transactionwill be processed by the expected combination of child datatransformation components and will be output by the parent datatransformation component at the correct time.

When a formal verification tool is used to verify an assertion, theformal verification tool may output an indication of whether or not theassertion is valid (i.e. the asserted property is true for all validstates or sequences of states), which may also be referred to herein asthe assertion being successfully verified. The output may be yes, theassertion is valid or has been successfully verified; no, the assertionis not valid (i.e. the asserted property it is not true or has failedfor at least one valid state or sequence of states) or has not beensuccessfully verified; or the formal verification was inconclusive. Theformal verification may be inconclusive, for example, because thecomputing-based device running the formal verification tool has run outof memory or because the formal verification tool has determined that acertain amount of progress has not been made after a predefined periodof time.

Where an assertion is not valid or has not been successfully verified,the formal verification tool may also output information indicating astate or sequence of states of the hardware design which causes theasserted property to fail. For example, the formal verification tool mayoutput a trace of the verification indicating at what point, state orsequence of states the failure occurred.

Once the verification of the hardware designs for the parent datatransformation components is complete the method 100 may end or themethod may proceed to block 106.

At block 106, a determination may be made as to whether theverifications in blocks 102 and 104 were successful. As described above,when a formal verification tool is used to verify an assertion for ahardware design, the formal verification tool may output a signal or aset of signals that indicates whether or not the assertion is valid(i.e. the asserted property is true for all valid states or sequence ofstates). In these cases, the determination as to whether theverifications were successful may be based on the output signal(s).

If it is determined that the verifications were successful (indicatingthat an instantiation of the hardware design for the main datatransformation component will work as expected) the method 100 mayproceed to block 108 where an integrated circuit embodying the main datatransformation component described by the hardware design ismanufactured. If, however, it is determined that one or more of theverifications performed in block 102 or block 104 was not successfulthen the method 100 may proceed to block 110.

At block 110, a determination is made as to whether any of theunsuccessful verifications were unsuccessful because they wereinconclusive (e.g. did not converge). A formal verification isinconclusive if the formal verification tool is unable to solve themathematical problem presented by the hardware design and the propertiesto verify. If, at least one of the unsuccessful verifications wasinconclusive, then the method 100 may proceed to block 112. If, however,none of the unsuccessful verifications were unsuccessful because theywere inconclusive, indicating they were unsuccessful because one of theproperties being verified was not found to be true for the hardwaredesign/abstracted hardware design, then the method 100 may proceed toblock 114.

At block 112, a new, or different, hierarchical set of datatransformation components is selected to represent the main datatransformation component. In some cases, the new, or different,hierarchical set of data transformation components may be generated bysub-dividing any data transformation component in the currenthierarchical set of data transformation components whose verificationwas inconclusive into at least two data transformation components. Forexample, if the verification of the hardware design for a leaf datatransformation component in the first hierarchical set of datatransformation components used to represent the main data transformationcomponent was inconclusive, it may have been that the leaf datatransformation component was too complex to verify as a single block orcomponent. Accordingly, that leaf data transformation component may besub-divided into a plurality of data transformation components. In otherwords, that leaf data transformation component may be converted to aparent data transformation components with a plurality of child datatransformation components. Although it is much more likely that theverification of the hardware design for a leaf data transformationcomponent will be inconclusive than the verification of the abstractedhardware design for a parent data transformation component, since thecomplex logic performing the data transformation(s) has been removedfrom the abstracted hardware design of a parent data transformationcomponent, it is possible for the verification of the abstractedhardware design for a parent data transformation component to beinconclusive. This may occur, for example, if there are complexinteractions between the child data transformation components of aparent data transformation component.

Once a new, or different, hierarchical set of data transformationcomponents has been selected to represent the main data transformationcomponent, the method 100 may proceed back to blocks 102 and 104 whereat least a portion of the leaf and parent data transformation componentsof the new hierarchical set of data transformation components areverified as described above. In some cases, only the leaf and parentdata transformation components which were not already verified in anearlier iteration of blocks 102 and 104 may be verified in a subsequentiteration of blocks 102 and 104. For example, if the only differencebetween the first hierarchical set of data transformation componentsthat was used for a first iteration of blocks 102 and 104 and the secondhierarchical set of data transformation components used in a seconditeration of blocks 102 and 104 is the change of a leaf datatransformation component into a parent data transformation componentwith two child/leaf data transformation components, then only that newparent data transformations and its children/leaf data transformationcomponents may be verified in the second iteration of blocks 102 and104.

At block 114, the hardware design for the main data transformationcomponent is modified to correct the error in the hardware design thatcaused the verification(s) to fail. In some cases, the informationindicating a state or sequence of states of the hardware design whichcaused an asserted property to fail (e.g. a counter example) may be usedto identify/locate the error in the hardware design. Once the hardwaredesign has been modified the modified hardware design may be re-verified(e.g. blocks 102-110 may be repeated for the modified hardware design).

Although in the example method 100 of FIG. 1 the data transformationcomponents are verified by working up through the hierarchy from theleaf data transformation components, this is not necessarily the case inother examples. In particular, the order in which the datatransformation components are verified is not important and can bechanged from the order described herein. In some examples, it would bepossible to verify multiple data transformation components in parallel,even if some of those multiple data transformation components beingverified in parallel have a parent-child relationship in the hierarchy.This is because the abstraction of the child data transformationcomponents in a hardware design for a parent data transformationcomponent makes the verification tasks of verifying the child and parentdata transformation components independent from each other.

Although in the example method 100 of FIG. 1 the verifications describedwith respect to block 102 (i.e. the verifications of the hardwaredesigns for the leaf data transformation components) are completed viaformal verification, in other examples the verifications of the hardwaredesigns for the leaf data transformation components may be completed viaother suitable verification methods. For example, alternatively theverification of the hardware design for one or more of the leaf datatransformation components may be performed via simulation-basedverification. However, depending on the type of component, the number ofinput transactions may be quite large which may make performing theverification via simulation intractable.

Although in the example method 100 of FIG. 1 the description of a childdata transformation component in the hardware design for the parent datatransformation component is completely replaced with an abstractedcomponent (e.g. a deterministic input/output pair) in other examples theabstracted component (e.g. deterministic input/output pair) onlyreplaces the logic that drives the data outputs and the control logic ofthe child data transformation component remains.

Reference is now made to FIG. 6 which illustrates an example system 600for verifying a hardware design for a main data transformationcomponent. The system 600 may be implemented by one or morecomputing-based devices, such as the computing-based device 700described below with respect to FIG. 7 . For example, one or more of thecomponents of the system 600 of FIG. 6 may be implemented as computerreadable instructions, which when executed by a computing-based device,cause the computing-based device to perform the functions of thecomponent described below.

As described above, the main data transformation component is formed of,or can be described as, a hierarchical set of data transformationcomponents. Each data transformation component in the hierarchy, exceptthe leaf data transformation components in the hierarchy, comprises atleast one data transformation component of the next lowest level. Atleast a portion of the hardware design for the main data transformationcomponent corresponds to each data transformation component of thehierarchical set of data transformation components. The portion of thehardware design for the main data transformation component thatcorresponds to a data transformation component of the hierarchical setof data transformation components is referred to herein as the hardwaredesign for that data transformation component.

The system 600 comprises the hardware design 602 for each leaf datatransformation component; a test bench comprising a set of one or moreassertions 604 for each leaf data transformation component; anabstracted hardware design 606 for each parent data transformationcomponent; a test bench comprising a set of one or more assertions 608for each parent data transformation component; and a formal verificationtool 610.

The hardware design 602 for a leaf data transformation componentcomprises a description of the structure and/or function of that leafdata transformation component. The abstracted hardware design 606 for aparent data transformation component comprises a description of thestructure and/or function of the parent data transformation component,wherein the description of any child data transformation componenttherein has been replaced with a description of a correspondingabstracted component. As described above, the corresponding abstractedcomponent for a data transformation component is configured to, for aspecific input transaction to the data transformation component, outputa specific output transaction with a deterministic causal relationshipthereto (e.g. at the correct time) according to the specification forthe data transformation component, wherein the specific input and outputtransactions are selectable from a plurality of possible inputtransactions and a plurality of possible output transactionsrespectively. The description of the abstracted component for a childdata transformation component may comprise a definition of a symbolicinput transaction to the child data transformation component, adefinition of a symbolic output transaction for the child datatransformation component, and one or more constraints thatdeterministically link the symbolic input transaction to the symbolicoutput transaction.

The test bench 604 for each of the leaf data transformation componentscomprises a set of one or more assertions, which if verified to be truefor the hardware design 602 for the leaf data transformation component,verifies that an instantiation of the hardware design for the leaf datatransformation component generates an expected output in response toeach of a plurality of input transactions. As described above, in somecases the plurality of input transactions may comprise all valid inputtransactions to the leaf data transformation component. The test bench604 may also comprise one or more constraints/assumptions and/ormodelling logic.

The test bench 608 for each of the parent data transformation componentscomprises a set of one or more assertions, which if verified to be truefor the abstracted hardware design 606 for the parent datatransformation component, verifies that an instantiation of theabstracted hardware design for the parent data transformation componentproduces an expected output transaction in response to each of aplurality of input transactions. As described above, in some cases, theplurality of input transactions for the parent data transformationcomponent may comprise all valid input transaction to the parent datatransformation component. The test bench 604 may also comprise one ormore constraints/assumptions and/or modelling logic

Verifying each set of assertions for the corresponding abstractedhardware design verifies that an instantiation of the hardware designfor the parent data transformation component will perform the desireddata transformations in the desired order on the appropriate data, notnecessarily that an instantiation of the hardware design for the parentdata transformation component produces the correct result. Together theverifications performed on the hardware designs for the leaf datatransformation components and the verifications performed on theabstracted hardware designs for the parent data transformationcomponents verify the overall correctness or the overall consistency ofthe hardware design for the main data transformation component.

Each test bench 604, 608 is linked to the corresponding hardwaredesign/abstracted hardware design so that the one or more assertions ofeach test bench are connected to the relevant signals of the hardwaredesigns so as to be able to evaluate the asserted property/properties.As described above, a test bench 604, 608 may be linked to a hardwaredesign by binding the test bench 604, 608 to the hardware design orincorporating the test bench into the hardware design.

As described above, the formal verification tool 610 is a software toolthat is capable of performing formal verification of a hardware design.

The hardware designs/abstracted hardware designs 602, 606 for the datatransformation components, the test benches (each comprising a set ofone or more assertions) 604, 608, and the bindings (if any) are loadedin the formal verification tool 610. The formal verification tool 610 isthen configured to formally verify each set of one or more assertionsfor the corresponding hardware design/abstracted hardware design.Specifically, for each leaf data transformation component the formalverification tool 610 is configured to verify that the set of one ormore assertions 604 for that leaf data transformation component is truefor the hardware design 602 for that leaf data transformation component;and for each parent data transformation component the formalverification tool 610 is configured to verify that the set of one ormore assertions 608 for that parent data transformation component istrue for the abstracted hardware design 606 for that parent datatransformation component.

When the formal verification tool 610 is used to verify an assertion,the formal verification tool 610 may output an indication of whether ornot the assertion is valid (i.e. the asserted property is true for allvalid states or sequence of states), which may also be referred toherein as the assertion being successfully verified. The output may beyes, the assertion is valid or has been successfully verified; no, theassertion is not valid (i.e. it is not true or has failed for at leastone valid state or sequence of states) or has not been successfullyverified; or the formal verification was inconclusive. The formalverification may be inconclusive, for example, because thecomputing-based device running the formal verification tool 610 has runout of memory or because the formal verification tool 610 has determinedthat a certain amount of progress has not been made after a predefinedperiod of time.

Where an assertion is not valid or has not been successfully verified,the formal verification tool 610 may also output information indicatinga state or sequence of states of the hardware design which causes theassertion to fail. For example, the formal verification tool 610 mayoutput a trace of the verification indicating at what point, state orsequence of states the failure occurred. In other words, the formalverification tool 610 may output a counter example.

Where one or more of the verifications is performed via anotherverification method, the system may additionally comprise one or moreother verification tools. For example, where one or more of theverifications is performed via simulation-based verification the systemmay comprise a simulation engine.

As is known to those of skill in the art, a simulation engine is asoftware tool capable of performing simulation-based verification of ahardware design. In particular, a simulation engine monitors the outputof one or more instantiations of the hardware design in response to eachinput vector in a test set and compares the outputs to known expectedoutputs to determine if the instantiation is behaving as expected.

A simulation engine may perform the simulation-based verification usingany known method. For example, the simulation engine may receive thehardware design in, for example HDL, convert the HDL to anotherlanguage, such as C, and perform the simulation on the C code; thesimulation engine may receive the hardware design as, for example, HDLand perform the simulation directly on the HDL; or the simulation enginemay implement the hardware design in hardware and perform the simulationon the hardware. Once the simulation is complete, the simulation enginemay output an indication of whether or not the hardware design passedthe simulation.

The methods and systems described above are configured to verify ahardware design for a main data transformation component by representingthe main data transformation component as a hierarchical set of datatransformation components, verifying the hardware design for each datatransformation component separately, and simplifying the verification ofthe hardware designs for all but the leaf data transformation componentsby abstracting the description of child data transformation componentstherein with a deterministic input-output pair. The Applicant submitsthat the representation of a data transformation component as ahierarchical set of data transformation components and the abstractionof lower level data transformation components in a data transformationcomponent as a deterministic input-output pair can also be used in thedesign process for designing a data transformation component.Specifically, it can be used to develop a specification for the hardwaredesign. However, instead of starting with the leaf data transformationcomponents and abstracting out the description of lower level componentsfrom the hardware design of higher level components, as in theverification case, the architect, engineer or hardware designer startswith the highest level data transformation component and at each leveldown in the hierarchy adds more detail to the operation of the higherlevel component.

Specifically, the architect, engineer or hardware designer may firstdevelop a high level specification for the data transformation componentin a formal verification language, such as, but not limited to, SVA,that describes: (a) the input(s) and output(s) of the level 1 component;(b) a set of data transformation components (which may be referred toherein as the level 2 data transformation components) which generate theoutput from the input; and (c) how the input data moves through thelevel 2 data transformation components to generate the output (i.e. theinteractions between the level 2 data transformation components).

This will now be described using an example data transformationcomponent that is configured to receive an input x and output y fivecycles after receiving x, wherein y is is the reciprocal square root ofx. Specifically, for this example data transformation component thespecification may define an input x and an output y.

The specification may then describe that the data transformationcomponent comprises a reciprocal component that receives an input andoutputs the reciprocal thereof; and a square root component thatreceives an input and produces the square root thereof. However, insteadof describing the mathematical operations that are performed by thereciprocal and square root components at this stage, the specificationmay describe only what the inputs and outputs of the reciprocal andsquare root components are, and how the inputs and outputs of thereciprocal and square root components are related to each other (i.e.which inputs influence which outputs, rather than a full description ofthe functionality). In other words, the specification stipulates ordefines a deterministic input-output pair for each data transformationcomponent of the first set of data transformation components. Forexample, the specification may describe for each level 2 datatransformation component: (a) a symbolic input transaction; (b) asymbolic output transaction; and (c) the deterministic relationshipbetween the symbolic input transaction and the symbolic outputtransaction. For example, the specification may describe that thesymbolic input transaction for the square root component is a value ythat is between 1 and 25, that a symbolic output transaction is a valuez that is between 1 and 5, and that when the symbolic input transactionoccurs the symbolic output transaction is output three cycles later.

The specification of the component may also describe how data movesthrough the component. For example, the specification may describe thatthe input to the main data transformation component is the input to thereciprocal component, the output of the reciprocal component is theinput to the square root component, and the output of the square rootcomponent is the output of the main data transformation component. Thespecification may then set out the requirement (e.g. specified by one ormore assertions) that for any valid input x to the reciprocal squareroot component (e.g. specified by one or more assumptions) that thecorresponding output y is produced 5 cycles therefrom, wherein theoutput is the result of a reciprocal operation and a square rootoperation.

In this way, the specification of such a data transformation componentis equivalent to the abstracted hardware design for that datatransformation component, as described above, in combination with theone or more assertions used to verify that abstracted hardware design.

The architect, engineer or hardware designer then analyses each level 2data transformation component to determine whether the specifics of thedata transformations performed by that level 2 data transformationcomponent are to be specified or whether the level 2 data transformationcomponent can be described as a set of level 3 data transformationcomponents. The process above is then repeated for each level 2 datatransformation component that can be described as a set of level 3 datatransformation components. Specifically, for each of these level 2 datatransformation components, the architect, engineer or hardware designerdevelops a specification for that level 2 data transformation componentthat describes (a) the inputs and outputs to the component, (b) a set ofdata transformation components (i.e. a set of level 3 datatransformation components) that process the input to generate theoutput; and (c) how the input data to the level 2 data transformationcomponent moves through the set of level 3 data transformationcomponents to generate the output, wherein each level 3 datatransformation component is represented by a deterministic input/outputpair. This process is repeated until a level is reached where thespecifics of the data transformations performed by each of the datatransformation components at that level is to be specified. A detailedspecification is then developed for each data transformation componentat that level from which a hardware design for that data transformationcomponent is generated.

Generally, when developing a specification for a hardware design it isdifficult to specify the data transformations performed by a datatransformation component in an abstract manner. This is becauseaccurately expressing the data transformation that is performed oftentakes the same amount of code and/or effort as developing the hardwaredesign itself. This makes the abstraction of data transformations in aspecification of limited use as it neither saves engineering time norreduces logical complexity. Accordingly, developing specifications inthe hierarchical manner described above allows architects, engineersand/or hardware designers to defer fully describing the datatransformations to a lower level, which reduces the engineering time tomove to the next level, and reduces the logic complexity at the currentlevel.

Writing the specification(s) of a data transformation component in aformal verification language (e.g. SVA) can offer a number of advantagesover writing the specification(s) in English (or any other human-spokenlanguage). Firstly, formal verification languages (e.g. SVA) generallyhave a flexible syntax which can define specific relational behaviourover time.

Secondly, specifications written in English (or any other humanlanguage) can be ambiguous as it is natural to interpret Englishlanguage descriptions based on one's own understanding of things/historywhich may not be the same way another person interprets the samedescription. In contrast, writing specifications in a formalverification language typically removes the ambiguity as it forces thewriter to specify the requirements using the formal verificationlanguage constructs available.

Thirdly, while writing specifications in a formal verification language(e.g. SVA) may take more time than writing a specification in English(or any other human language) the formal verification specification maysave time by removing ambiguity. The inherent ambiguity in humanlanguage also means that one doesn't automatically question themselveswhen writing a specification in a human language as one assumes it willbe interpreted in the same manner as the writer had intended. Incontrast, writing a specification in a formal verification languageforces the architect, engineer or hardware developer to think about andclarify the ambiguity. In other words, writing a specification in aformal verification language forces the architect, engineer or hardwaredeveloper to be more precise.

Fourthly, due to the ambiguity in human language specifications itcannot be guaranteed that a hardware design for a data transformationcomponent that conforms to the specification will work in a higher leveldata transformation component. As a specification written in a formalverification language removes the ambiguity, it also removes this issue.

Lastly, writing the specification of the data transformation componentin a formal verification language (e.g. SVA) allows the hardware designfor such a data transformation component to be easily verified using ahierarchical formal verification method such as the method of FIG. 1 .Specifically, the specifications of the parent data transformationcomponents represent the abstracted hardware designs of the parent datatransformation components described above and thus can be directly usedto verify the parent data transformation components.

FIG. 7 illustrates various components of an exemplary computing-baseddevice 700 which may be implemented as any form of a computing and/orelectronic device, and in which embodiments of the methods and systemsdescribed herein may be implemented.

Computing-based device 700 comprises one or more processors 702 whichmay be microprocessors, controllers or any other suitable type ofprocessors for processing computer executable instructions to controlthe operation of the device in order to verify a hardware design for adata transformation component. In some examples, for example where asystem on a chip architecture is used, the processors 702 may includeone or more fixed function blocks (also referred to as accelerators)which implement a part of the method of verifying a hardware design fora data transformation component, in hardware (rather than software orfirmware). Platform software comprising an operating system 704 or anyother suitable platform software may be provided at the computing-baseddevice to enable application software, such as a formal verificationtool, to be executed on the device.

The computer executable instructions may be provided using anycomputer-readable media that is accessible by computing-based device700. Computer-readable media may include, for example, computer storagemedia such as memory 706 and communications media. Computer storagemedia (i.e. non-transitory machine-readable media), such as memory 706,includes volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules orother data. Computer storage media includes, but is not limited to, RAM,ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM,digital versatile disks (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other non-transmission medium that can be usedto store information for access by a computing device. In contrast,communication media may embody computer readable instructions, datastructures, program modules, or other data in a modulated data signal,such as a carrier wave, or other transport mechanism. As defined herein,computer storage media does not include communication media. Althoughthe computer storage media (i.e. non-transitory machine-readable media,e.g. memory 706) is shown within the computing-based device 700 it willbe appreciated that the storage may be distributed or located remotelyand accessed via a network or other communication link (e.g. usingcommunication interface 708).

The computing-based device 700 also comprises an input/output controller710 arranged to output display information to a display device 712 whichmay be separate from or integral to the computing-based device 700. Thedisplay information may provide a graphical user interface. Theinput/output controller 710 is also arranged to receive and processinput from one or more devices, such as a user input device 714 (e.g. amouse or a keyboard). This user input may be used to initiateverification. In an embodiment the display device 712 may also act asthe user input device 714 if it is a touch sensitive display device. Theinput/output controller 710 may also output data to devices other thanthe display device, e.g. a locally connected printing device (not shownin FIG. 7 ).

FIG. 8 shows a computer system in which any of the data transformationcomponents described herein may be implemented. The computer systemcomprises a CPU 802, a GPU 804, a memory 806 and other devices 814, suchas a display 816, speakers 818 and a camera 820. A data transformationcomponent 810 (such as, but not limited to, the data transformationcomponent 200 of FIG. 2 ) is implemented on the GPU 804. In otherexamples, the data transformation component 810 may be implemented onthe CPU 802. The components of the computer system can communicate witheach other via a communications bus 822.

Generally, any of the functions, methods, techniques or componentsdescribed above can be implemented in software, firmware, hardware(e.g., fixed logic circuitry), or any combination thereof. The terms“module,” “functionality,” “component”, “element”, “unit”, “block” and“logic” may be used herein to generally represent software, firmware,hardware, or any combination thereof. In the case of a softwareimplementation, the module, functionality, component, element, unit,block or logic represents program code that performs the specified taskswhen executed on a processor. The algorithms and methods describedherein could be performed by one or more processors executing code thatcauses the processor(s) to perform the algorithms/methods. Examples of acomputer-readable storage medium include a random-access memory (RAM),read-only memory (ROM), an optical disc, flash memory, hard disk memory,and other memory devices that may use magnetic, optical, and othertechniques to store instructions or other data and that can be accessedby a machine.

The terms computer program code and computer readable instructions asused herein refer to any kind of executable code for processors,including code expressed in a machine language, an interpreted languageor a scripting language. Executable code includes binary code, machinecode, bytecode, code defining an integrated circuit (such as a hardwaredescription language or netlist), and code expressed in a programminglanguage code such as C, Java or OpenCL. Executable code may be, forexample, any kind of software, firmware, script, module or librarywhich, when suitably executed, processed, interpreted, compiled,executed at a virtual machine or other software environment, cause aprocessor of the computer system at which the executable code issupported to perform the tasks specified by the code.

A processor, computer, or computer system may be any kind of device,machine or dedicated circuit, or collection or portion thereof, withprocessing capability such that it can execute instructions. A processormay be any kind of general purpose or dedicated processor, such as aCPU, GPU, System-on-chip, state machine, media processor, anapplication-specific integrated circuit (ASIC), a programmable logicarray, a field-programmable gate array (FPGA), or the like. A computeror computer system may comprise one or more processors.

It is also intended to encompass software which defines a configurationof hardware as described herein, such as HDL (hardware descriptionlanguage) software, as is used for designing integrated circuits, or forconfiguring programmable chips, to carry out desired functions. That is,there may be provided a computer readable storage medium having encodedthereon computer readable program code in the form of an integratedcircuit definition dataset (e.g. hardware design) that when processed(i.e. run) in an integrated circuit manufacturing system configures thesystem to manufacture a device (e.g. processor or other computing-baseddevice) comprising any apparatus (e.g. data transformation component)described herein. An integrated circuit definition dataset may be, forexample, an integrated circuit description.

Therefore, there may be provided a method of manufacturing, at anintegrated circuit manufacturing system, a data transformation componentas described herein. Furthermore, there may be provided an integratedcircuit definition dataset (e.g. hardware design) that, when processedin an integrated circuit manufacturing system, causes the method ofmanufacturing an integrated circuit embodying the data transformationcomponent to be performed.

An integrated circuit definition dataset (e.g. hardware design) may bein the form of computer code, for example as a netlist, code forconfiguring a programmable chip, as a hardware description languagedefining hardware suitable for manufacture in an integrated circuit atany level, including as register transfer level (RTL) code, ashigh-level circuit representations such as Verilog or VHDL, and aslow-level circuit representations such as OASIS (RTM) and GDSII. Higherlevel representations which logically define hardware suitable formanufacture in an integrated circuit (such as RTL) may be processed at acomputer system configured for generating a manufacturing definition ofan integrated circuit in the context of a software environmentcomprising definitions of circuit elements and rules for combining thoseelements in order to generate the manufacturing definition of anintegrated circuit so defined by the representation. As is typically thecase with software executing at a computer system so as to define amachine, one or more intermediate user steps (e.g. providing commands,variables etc.) may be required in order for a computer systemconfigured for generating a manufacturing definition of an integratedcircuit to execute code defining an integrated circuit so as to generatethe manufacturing definition of that integrated circuit.

An example of processing an integrated circuit definition dataset (e.g.hardware design) at an integrated circuit manufacturing system so as toconfigure the system to manufacture an integrated circuit embodying adata transformation component will now be described with respect to FIG.9 .

FIG. 9 shows an example of an integrated circuit (IC) manufacturingsystem 902 which is configured to manufacture an integrated circuitembodying a data transformation component as described in any of theexamples herein. In particular, the IC manufacturing system 902comprises a layout processing system 904 and an integrated circuitgeneration system 906. The IC manufacturing system 902 is configured toreceive an IC definition dataset, such as a hardware design, (e.g.defining a data transformation component as described in any of theexamples herein), process the IC definition dataset, and generate an ICaccording to the IC definition dataset (e.g. which embodies a datatransformation component as described in any of the examples herein).The processing of the IC definition dataset configures the ICmanufacturing system 902 to manufacture an integrated circuit embodyinga data transformation component as described in any of the examplesherein.

The layout processing system 904 is configured to receive and processthe IC definition dataset (e.g. hardware design) to determine a circuitlayout. Methods of determining a circuit layout from an IC definitiondataset are known in the art, and for example may involve synthesisingRTL code to determine a gate level representation of a circuit to begenerated, e.g. in terms of logical components (e.g. NAND, NOR, AND, OR,MUX and FLIP-FLOP components). A circuit layout can be determined fromthe gate level representation of the circuit by determining positionalinformation for the logical components. This may be done automaticallyor with user involvement in order to optimise the circuit layout. Whenthe layout processing system 904 has determined the circuit layout itmay output a circuit layout definition to the IC generation system 906.A circuit layout definition may be, for example, a circuit layoutdescription.

The IC generation system 906 generates an IC according to the circuitlayout definition, as is known in the art. For example, the ICgeneration system 906 may implement a semiconductor device fabricationprocess to generate the IC, which may involve a multiple-step sequenceof photo lithographic and chemical processing steps during whichelectronic circuits are gradually created on a wafer made ofsemiconducting material. The circuit layout definition may be in theform of a mask which can be used in a lithographic process forgenerating an IC according to the circuit definition. Alternatively, thecircuit layout definition provided to the IC generation system 906 maybe in the form of computer-readable code which the IC generation system906 can use to form a suitable mask for use in generating an IC.

The different processes performed by the IC manufacturing system 902 maybe implemented all in one location, e.g. by one party. Alternatively,the IC manufacturing system 902 may be a distributed system such thatsome of the processes may be performed at different locations, and maybe performed by different parties. For example, some of the stages of:(i) synthesising RTL code representing the IC definition dataset to forma gate level representation of a circuit to be generated, (ii)generating a circuit layout based on the gate level representation,(iii) forming a mask in accordance with the circuit layout, and (iv)fabricating an integrated circuit using the mask, may be performed indifferent locations and/or by different parties.

In other examples, processing of the integrated circuit definitiondataset at an integrated circuit manufacturing system may configure thesystem to manufacture an integrated circuit embodying datatransformation component without the IC definition dataset beingprocessed so as to determine a circuit layout. For instance, anintegrated circuit definition dataset may define the configuration of areconfigurable processor, such as an FPGA, and the processing of thatdataset may configure an IC manufacturing system to generate areconfigurable processor having that defined configuration (e.g. byloading configuration data to the FPGA).

In some embodiments, an integrated circuit manufacturing definitiondataset, when processed in an integrated circuit manufacturing system,may cause an integrated circuit manufacturing system to generate adevice as described herein. For example, the configuration of anintegrated circuit manufacturing system in the manner described abovewith respect to FIG. 9 by an integrated circuit manufacturing definitiondataset may cause a device as described herein to be manufactured.

In some examples, an integrated circuit definition dataset could includesoftware which runs on hardware defined at the dataset or in combinationwith hardware defined at the dataset. In the example shown in FIG. 9 ,the IC generation system may further be configured by an integratedcircuit definition dataset to, on manufacturing an integrated circuit,load firmware onto that integrated circuit in accordance with programcode defined at the integrated circuit definition dataset or otherwiseprovide program code with the integrated circuit for use with theintegrated circuit.

The implementation of concepts set forth in this application in devices,apparatus, modules, and/or systems (as well as in methods implementedherein) may give rise to performance improvements when compared withknown implementations. The performance improvements may include one ormore of increased computational performance, reduced latency, increasedthroughput, and/or reduced power consumption. During manufacture of suchdevices, apparatus, modules, and systems (e.g. in integrated circuits)performance improvements can be traded-off against the physicalimplementation, thereby improving the method of manufacture. Forexample, a performance improvement may be traded against layout area,thereby matching the performance of a known implementation but usingless silicon. This may be done, for example, by reusing functionalblocks in a serialised fashion or sharing functional blocks betweenelements of the devices, apparatus, modules and/or systems. Conversely,concepts set forth in this application that give rise to improvements inthe physical implementation of the devices, apparatus, modules, andsystems (such as reduced silicon area) may be traded for improvedperformance. This may be done, for example, by manufacturing multipleinstances of a module within a predefined area budget.

The applicant hereby discloses in isolation each individual featuredescribed herein and any combination of two or more such features, tothe extent that such features or combinations are capable of beingcarried out based on the present specification as a whole in the lightof the common general knowledge of a person skilled in the art,irrespective of whether such features or combinations of features solveany problems disclosed herein. In view of the foregoing description itwill be evident to a person skilled in the art that variousmodifications may be made within the scope of the invention.

What is claimed is:
 1. A method of generating an integrated circuithardware design for a main data transformation component that isconfigured to perform a data transformation on one on one or more inputsto produce one or more outputs, the method comprising: (a) generating ahigh level specification for the main data transformation component in aformal verification language that defines (i) the one or more inputs andthe one or more outputs of the main data transformation component, (ii)a set of one or more child data transformation components, and (iii)movement of the one or more inputs through the set of one or more childdata transformation components to generate the one or more outputs; (b)for each child data transformation component: determining whether thechild data transformation component is to be represented by a set of oneor more further child data transformation components, in response todetermining that the child data transformation component is not to berepresented by a set of one or more further child data transformationcomponents, generating a detailed specification for that child datatransformation component in a formal verification language, in responseto determining that the child data transformation component is to berepresented by a set of one or more further child data transformationcomponents, generating a high level specification for the child datatransformation component in a formal verification language that defines(i) one or more inputs and one or more outputs of the child datatransformation component, (ii) the set of one or more further child datatransformation components, and (iii) movement of the one or more inputsof the child data transformation component through the set of one ormore further child data transformation components to generate the one ormore outputs of the child data transformation component, and repeating(b) for the set of one or more further child data transformationcomponents; (c) generating an integrated circuit hardware design foreach detailed specification; (d) generating an integrated circuithardware design for the main data transformation component from theintegrated circuit hardware designs for the detailed specifications; and(e) verifying the integrated circuit hardware design for the main datatransformation component using the high level specifications and theintegrated circuit hardware designs for the detailed specifications. 2.The method of claim 1, wherein the definition of a child datatransformation in a high level specification does not describe the datatransformation performed by that child data transformation component. 3.The method of claim 2, wherein the definition of child datatransformation component in a high level specification comprises adefinition of a symbolic input transaction to the child datatransformation component, a definition of a symbolic output transactionof the child data transformation component, and one or more constraintsthat establish a deterministic causal relationship between the symbolicinput transaction and the symbolic output transaction.
 4. The method ofclaim 3, wherein the symbolic input transaction to a child datatransformation component is a symbolic constant that represents thevalid input transactions to that child data transformation component. 5.The method of claim 3, wherein the symbolic output transaction of achild data transformation component is a symbolic constant thatrepresents the valid output transactions for that child datatransformation component.
 6. The method of claim 3, wherein the one ormore constraints that establish a deterministic causal relationshipbetween the symbolic input transaction and the symbolic outputtransaction are implemented by one or more formal assumption statements.7. The method of claim 3, wherein the definition of movement of the oneor more inputs through the set of one or more child data transformationcomponents to generate the one or more outputs in a high levelspecification comprises a description of a relationship between thesymbolic input and output transactions of the set of one or more childdata transformation components.
 8. The method of claim 1, wherein eachchild data transformation component is configured to perform a datatransformation on one or more inputs to generate one or more outputs. 9.The method of claim 1, wherein verifying the integrated circuit hardwaredesign for the main data transformation component using the high levelspecifications and the integrated circuit hardware designs for thedetailed specifications comprises verifying, for each high levelspecification and each integrated circuit hardware design for a detailedspecification, that an instantiation thereof generates an expectedoutput transaction in response to each of a plurality of test inputtransactions.
 10. The method of claim 9, wherein verifying that aninstantiation of an integrated circuit hardware design for a detailedspecification generates an expected output transaction in response to aninput transaction comprises verifying that the instantiation of theintegrated circuit hardware design generates an output transaction, witha deterministic causal relationship to the input transaction, that iscorrect with respect to a data transformation set out in the detailedspecification.
 11. The method of claim 9, wherein verifying that aninstantiation of a high level specification generates an expected outputtransaction in response to an input transaction comprises verifying thatan instantiation of the high level specification generates an outputtransaction, with a deterministic causal relationship to the inputtransaction, that has been generated by processing the input transactionthrough an expected combination of the set of one or more child datatransformation components defined in the high level specification. 12.The method of claim 9, wherein the plurality of test input transactionsfor an integrated circuit hardware design for a detailed specificationcomprises all valid input transactions to the child data transformationcomponent corresponding to the detailed specification.
 13. The method ofclaim 9, wherein the plurality of test input transactions for a highlevel specification comprises all valid input transactions to the datatransformation component corresponding to the high level specification.14. The method of claim 9, wherein verifying that an instantiation ofthe integrated circuit hardware design for a detailed specificationgenerates an expected output transaction in response to each of aplurality of test input transactions comprises formally verifying, usinga formal verification tool, that the instantiation of the integratedcircuit hardware design generates an expected output transaction inresponse to each of the plurality of test input transactions.
 15. Themethod of claim 1, further comprising outputting one or more controlsignals indicating whether the verification was successful.
 16. Themethod of claim 1, further comprising, in response to determining thatthe verification was not successful, modifying the hardware design forthe main data transformation component to generate a modified hardwaredesign for the main data transformation component.
 17. The method ofclaim 1, further comprising, in response to determining that theverification was successful, manufacturing, using an integrated circuitmanufacturing system, an integrated circuit embodying the main datatransformation component according to the integrated circuit hardwaredesign for the main data transformation component.
 18. The method ofclaim 1, wherein, when processed at an integrated circuit manufacturingsystem, the integrated circuit hardware design for the main datatransformation component configures the integrated circuit manufacturingsystem to manufacture an integrated circuit embodying the main datatransformation component.